The structure and operation of a conventional data communication control device to be contrasted with a data communication control device hereof will be described below with reference to FIGS. 1 to 5.
FIG. 1 is a block diagram illustrating the structure of a data communication control device to be contrasted with the data communication control device hereof. FIG. 2 is a block diagram illustrating the relation between a direct memory access controller in the data communication control device of FIG. 1 and a hardware command queue. Hereinafter the direct memory access is also referred to as “DMA”, and the hardware command queue is also referred to as “HW command queue” for short. In the drawing, of a plurality of controller modules, seven controller modules 110-1 to 110-7 (CM#0 to CM#6) are illustrated on-behalf of them.
As illustrated in FIG. 1, in the conventional data communication control device 100, DMA controllers 120-1 to 120-7 are provided in the controller modules 110-1 to 110-7 respectively. Further, channels CH0 to CH6 are prepared corresponding to the controller modules 110-1 to 110-7 respectively (see FIG. 2). The controller modules 110-1 to 110-7 each have a host interface provided in an entrance portion, which will be connected to an outside server (not illustrated in FIG. 1). The controller modules 110-1 to 110-7 control data transfer using direct memory access executed between the controller modules 110-1 to 110-7 according to a request from the outside server. The data sent out from a certain controller module is transferred to other controller module of transfer destination through a switch unit 130, which is a communication path between the controller modules.
Further, the controller modules 110-1 to 110-7 of FIG. 1 each have: a CPU (Central Processing Unit) 140-1 to 140-7 which serves as firmware for overall controlling various constituents in the controller module including the DMA controller 120-1 to 120-7; and a memory unit 160-1 to 160-7 including a memory for holding various kinds of data transferred from the outside server and various programs and others for executing data transfer using direct memory access between the controller modules. The CPUs 140-1 to 140-7, memory units 160-1 to 160-7, DMA controllers 120-1 to 120-7 and others are mutually connected by respective memory controller hubs 150-1 to 150-7. It is noted that the memory controller hubs are abbreviated to MCH in FIG. 1. Herein, “firmware” refers to a combination of software and hardware necessary to control data communication between the controller modules.
Next, the structure of the inside of the DMA controllers and the specifications thereof will be described in outline with reference to FIG. 2. As illustrated in FIG. 2, a certain DMA controller (e.g. the first DMA controller 120-1 (CM#0)) controls data communication through direct memory access executed between controller modules. As many channels (e.g. CH0-CH6) as the controller modules of transfer destinations are prepared, one for each controller module.
In the corresponding DMA controller, each channel has a hardware data storing part (e.g. the hardware data storing part 60-1 in the DMA controller 120-1). The hardware data storing part is usually termed “hardware command queue (or HW command queue)”, and is capable of holding data containing commands involved with data transfer requests. The commands (DC) in the HW command queue are executed from the head in order, and two or more commands are never executed concurrently in the HW command queue. Aside from the channels, the DMA controllers are provided with engines EG-1 and GE-2 which actually implement direct memory access. The number of the engines EG-1 and EG-2 is smaller than that of the channels. The engines EG-1 and EG-2 are shared by all the channels, and therefore they are not bound to a particular channel fixedly. Herein, the engines EG-1 and EG-2 acquire a command from a channel by a round-robin method to perform an appropriate process. However, the hardware of the DMA controllers has no knowledge of the order in which the commands were stuffed in the HW command queue. In this case, the controller modules having different characteristics are assigned different roles respectively, which produces a bias in process such that control data of a small size is transferred to a controller module and user data of a large size is transferred to another controller module.
FIG. 3 is a schematic diagram illustrating a situation where two or more commands are stuffed in the HW command queue of FIG. 2. FIG. 4 is a schematic diagram illustrating the way a new command is stuffed in the HW command queue of FIG. 3. FIG. 5 is a schematic diagram illustrating a situation where command sinking occurs in the channel 0 of the HW command queue of FIG. 4. Here, the mechanism of the occurrence of command sinking in a particular channel (e.g. channel 0) of the HW command queue will be described with reference to FIGS. 3 to 5.
First, it is assumed that commands have been stuffed in the HW command queue in the DMA controller as illustrated in FIG. 3 at a certain point of time. As is clear from the situation of FIG. 3, a larger number of commands (SDC) of small-size data are stuffed in the channel 0 (CH0), and a smaller number of commands (LDC) of large-size data are stuffed in the other channels (CH1-CH6). Here, the numerals (1-18) in the commands show the ordinal number of a process which is due to be executed at this point of time.
Next, as to the HW command queue in the situation of FIG. 2 it is assumed that new commands are stuffed in the channel 1 (CH1) and channel 2 (CH2) as illustrated in FIG. 4. In this case, although the commands have been issued in the nineteenth and twentieth turns originally, these commands in the channels 1 (CH1) and 2 (CH2) will be executed in the sixteenth and seventeenth turns as illustrated in FIG. 4. This is because the engines EG-1 and EG-2 pull the commands out of the channels 1 (CH1) and 2 (CH2) according to the round-robin method.
In other words, when a bias arises in the data size or number of commands involved with data transfer requests, an event such that a command of the channel 0 (CH0), which has been stuffed earlier, is passed by a command of another channel, which has been stuffed later, and the earlier stuffed command ends up being processed after the later stuffed one would take place.
As described above, when the bias in the data size or number of data remains between the channels, commands of other channels, which have been stuffed later, go ahead of a command of the channel 0 (CH0) of the HW command queue one after another as illustrated in FIG. 4, and the position of processing the command of the channel 0 in the sequence is changed in succession to latter one, e.g. twenty-first, . . . , ninety-eighth or ninety-ninth position. Thus, the problem that sinking of the command of the channel 0 (CH0) takes place, and the command of the Channel 0 is not processed within a prescribed length of time during which the firmware is monitoring, i.e. the command goes into time-out arises. As described above, the term “sinking” means that a condition such that the number of commands stored in a queue increases compared the number of commands stored in the other queues.
Such problem is attributed to the fact that the order of storing commands involved with different channels is not managed across the channels, and therefore one channel's command would pass another channel's command in the turn of command processing. This tendency is more remarkable as the biases in data size and number of data targeted by the commands stuffed in the HW command queue is larger.
The conventional data communication control device discloses a memory device, applying a measure to prevent sinking to a read command and a write command separately, managing the time when each command is received for the purpose of making the read command less prone to sink, and having a command queuing function for preferentially executing a command which has not been executed for a fixed length of time since the reception.
The conventional data communication control device discloses a method of activating an input-output device which includes: measuring the start stand-by time of an input/output instruction in an input/output processing device; verifying the start stand-by time each time the input/output instruction is extracted from an input/output queue; and preferentially executing the input/output instruction which has not been started while having been stored in the input/output queue.
Japanese Laid-open Patent Publication No. 2001-249770 and Japanese Laid-open Patent Publication No. 2002-342252 are disclosed.